[GDS|Entropy] <gds### [at] hotmailcom> wrote:
> I love ^....why in the nine hells did they ditch it anyway?

  The problem with the operator ^ in scripting languages which are by
necessity ascii-based is that its interpretation is ambiguous.

  In contrast with other binary operators, such as - and /, where it's
clear that the precedence is left-to-right, the same is not so clear for
the binary operator ^.

  By "left-to-right precedence" I mean that, for example "2-3-4" is
interpreted as "(2-3)-4" and not as "2-(3-4)". Likewise for "2/3/4".

  With ^ the interpretation becomes more difficult. Should "2^3^4" be
interpreted as "(2^3)^4" or as "2^(3^4)"? Needless to say that these two
interpretations give different results (4096 vs 2417851639229258349412352).

  There are two possible arguments in this:

1) Operator ^ should work in the same way as all the other binary operators,
for consistency. Thus it should be interpreted as "(2^3)^4".

2) Operator ^ actually denotes the "superscript" of mathematical formulae,
which means that "2^3^4" is actually "2 superscript 3 superscript 4", which
in mathematics is interpreted as "2^(3^4)".

  The most common interpretation in languages out there (which support
operator ^ as the power operator) is #2, but it's not a writte-in-stone
rule.

  Another problem is the interpretation of the unary minus alongside the
binary operator ^.

  The unary minus has higher precedence than any other operator, which
means that "2^-3" is not a syntax error (because "-3" has higher precedence
than the "^").

  However, if the unary minus has higher precendence than ^, then it causes
another interpretation problem: More specifically "-3^2" would be interpreted
as "(-3)^2", which results in 9. However, the most commonly assumed result
of "-3^2" is -9. In other words, it's usually assumed that the unary minus
in front of a power operation has lower precedence.

  It is perfectly possible (end eg. with a recursive descent parser fairly
trivial) to parse an expression like "-2^-3^-4" as "-(2^(-3^(-4)))", but
it's still a question of definition whether that's really the "correct"
interpretation (because there is no such a thing as "correct" in this case,
as there's no universal rule).

  Personally I wouldn't mind if POV-Ray supported the binary ^ operator
with those precedence rules, but the pov-team has decided to not to take
a stance on this subject, and instead prefer the completely unambiguous
pow(x,y) function.

-- 
                                                          - Warp

Post a reply to this message